Most programming languages include a set of parameter/message passing mechanisms to pass data from one function or method to another. These mechanisms are often based on a mechanical metaphor that defines a “machine,” which is insensitive to its context. Traditionally, reducing context sensitivity was important to sound machine design. Soundly designed machines traditionally have a rigidly defined small number of inputs and outputs. Machines are analogous to software functions and methods. Machine input/output interfaces are analogous to programming language parameter/message passing mechanisms. In the mechanical metaphor, a user determines the machine inputs. Thus “agency” is never in the machine, but is rather always in the machine user. Similarly, in the programming language paradigm, the “user” of the function or method determines what the inputs and outputs will be.
Although the mechanical metaphor is good for repeatedly performing simple tasks accurately, one disadvantage of machines, and thus mechanisms, is that machines do not react well to environmental changes. When environments change, machines do not typically adapt to such environmental changes. Similarly, typical programming language parameter/message passing mechanisms have an inherent mechanical rigidity, which inhibits adaptation to environmental changes. For example, a business application system is a computer model of a frequently changing human process. Human processes are complex adaptive systems, as they adapt to environmental changes. However, application software is typically very difficult to change because it uses parameter-passing mechanisms that “lock in” an original design, which becomes outdated as the human process changes. A disadvantage of typical programming language parameter/message passing mechanisms is that they have an inherent mechanical rigidity, which inhibits systems from adapting to environmental changes.
According to one prior art programming language, functions and their parameters must be declared at design time. Additionally, callers of a function must call the function using the function's name and its parameter names and types. With many parameter/message passing mechanisms, both calling and called routines must specify how parameters will be represented and interpreted. Parameter/message passing mechanisms also require that parameter representations be expressed at design time. When systems are modified, the parameter representations must be modified everywhere they are called. In large systems, parameters can be difficult to find and therefore, modifying parameters can be extremely difficult and expensive.
According to another prior art programming language, all parameter evaluations are done before the called routine or function begins to execute. One disadvantage of this prior art programming language is that early parameter evaluation can lead to redundant computation when certain parameters are not used within the routine or function.